Thanks for this and the benchmarks! I like how it's laid out very similarly to the otlp-proto-common.

removal of ~200 lines of Windows getting-started and opentracing-shim jobs from test_0.yml

I believe they were moved to test_1.yml

Thanks for this and the benchmarks! I like how it's laid out very similarly to the otlp-proto-common.

removal of ~200 lines of Windows getting-started and opentracing-shim jobs from test_0.yml

I believe they were moved to test_1.yml

That was my goal, although I made a few alterations/simplifications.

Hi, excited to see this progressing! We have a use case where OTLP JSON would be really valuable.

We're building an observability pipeline where traces need to be both forwarded to a backend (Langfuse) and persisted to disk as OTLP JSON files for audit/replay purposes. The current opentelemetry-exporter-otlp-proto-http only supports protobuf serialization, so we ended up writing a workaround using MessageToJson:

  from google.protobuf.json_format import MessageToJson
  from opentelemetry.exporter.otlp.proto.common.trace_encoder import encode_spans
  from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter
  from opentelemetry.sdk.trace.export import SpanExportResult


  class OTLPJsonSpanExporter(OTLPSpanExporter):
      """OTLPSpanExporter that sends OTLP JSON instead of protobuf."""

      def export(self, spans):
          try:
              encoded = encode_spans(spans)
              serialized = MessageToJson(encoded, preserving_proto_field_name=True)
              self._session.headers["Content-Type"] = "application/json"
              return self._export(serialized.encode("utf-8"))
          except Exception:
              return SpanExportResult.FAILURE

This works but depends on internal APIs (encode_spans, _export). Having an official otlp-json-common package would give us a stable, supported way to produce spec-compliant OTLP JSON, both for HTTP export and file persistence.

Would love to see this merged. Happy to help test!

Lots of excellent functionality here, thanks. Before enabling, should address proto and json throwing exceptions on bad data. LGTM otherwise.

@pmcollins Thanks! I've created #5050. Do you have any preference over the two solutions I've outlined?